Перейти к основному содержимому

Эластичное масштабирование и упаковка по фазам

Версия: 1.0 Дата: 25.04.2026 Статус: Утверждён

Платформа Vitiana проектируется как эластичная самомасштабирующаяся система (elastically auto-scaling system) с самого первого документа.

Стратегия упаковки вычислений (compute packaging) — не одна и та же на всех этапах. Она разворачивается поэтапно, и каждый этап зафиксирован в документации заранее с обоснованием: когда переключаться, на что, почему.

Зафиксировано 25.04.2026.

Главный тезис​

Где запускается каждый сервис (общий контейнер, выделенный контейнер, выделенный сервер, serverless function, dedicated infrastructure) — это решение с явным триггером, не «как получится». Все 4 фазы упаковки и метрические триггеры перехода — описаны в документации с самого начала, не «когда понадобится».

Эластичное масштабирование как baseline​

Что включает с первого дня​

  • Горизонтальное масштабирование (horizontal scaling) как первичный путь для всех stateless контуров.
  • Автоматическое масштабирование (auto-scaling) на основе метрик нагрузки: CPU, memory, queue lag, request rate, p95/p99 latency, custom domain metrics (active quotes, pending bookings, supplier pressure).
  • Изоляция execution contours с независимым масштабированием. См. operations/deployment.md.
  • Capacity envelope per tenant tier — гарантированная ёмкость для премиум-партнёров, fair-share для остальных.
  • Backpressure discipline на async-очередях для предотвращения каскадных сбоев.
  • Graceful degradation при перегрузке — не отказ, а понижение качества (читать — да, новый booking — отказать с retry-after).

Что не должно быть в документах​

  • «Масштабируем потом» / «MVP без auto-scaling».
  • Жёсткие cluster sizes как final («3 ноды PostgreSQL навсегда»).
  • Vertical scaling как primary strategy для stateless workloads.
  • Подход «один контейнер на все».

Стратегия упаковки вычислений по фазам​

Каждый execution contour имеет свой профиль: latency-sensitive / throughput-heavy / stateful / replay-sensitive / financially-critical. Упаковка зависит от профиля и фазы зрелости платформы.

Фаза 1 — Bootstrap (controlled internal platform)​

Цель: доказать viability ядра, ingestion, offer/quote/booking path.

Упаковка:

  • Большая часть сервисов — общий containerized environment (single Kubernetes namespace или managed container platform).
  • PostgreSQL — managed instance с read replicas (Cloud SQL / RDS paradigm).
  • Redis — managed cache.
  • OpenSearch — managed instance.
  • Async-очереди — managed broker (managed Kafka / Pub/Sub / SQS paradigm).

Обоснование: скорость доставки и единый operational model важнее infrastructure optimization. Стоимость auto-scaling ниже стоимости человеческого operations.

Триггеры выхода из фазы (когда документ обязан вести в Фазу 2):

  • Регулярное превышение auto-scaling envelope в одном контуре.
  • Латентность одного контура начинает деградировать другие из-за shared resources.
  • Стоимость инфраструктуры на одного активного tenant превышает порог X.

Фаза 2 — Service isolation (controlled external beta)​

Цель: разделить execution contours по operational profile.

Упаковка:

  • Latency-sensitive контуры (search, partner API, gateway) — отдельные deployment groups с гарантированной capacity.
  • Throughput-heavy контуры (ingestion, intake workers) — отдельный pool, не влияющий на latency-sensitive.
  • Replay-sensitive jobs — изолированный compute pool (replay не должен влиять на live).
  • Financially-critical контуры (booking commit, settlement event generation) — изолированный compute pool с отдельными SLO.
  • PostgreSQL — primary с read replicas; начинается обсуждение partitioning.
  • Каналы событий — отдельные кластеры или dedicated topics для critical event families.

Обоснование: разные contours имеют разные SLO, и shared compute создаёт contention.

Триггеры выхода из фазы:

  • Один tenant создаёт нагрузку, которая влияет на других.
  • Конкретный supplier создаёт ingestion peak, который перекладывает offer assembly.
  • Settlement event volume требует dedicated processing capacity.

Фаза 3 — Workload-specific packaging (production-capable)​

Цель: оптимизировать стоимость и SLO.

Упаковка:

  • Тяжёлые ingestion jobs (Rust) — могут переехать на dedicated nodes / spot instances для cost optimization.
  • Latency-critical core (Go) — premium nodes, gateway-co-located.
  • Search engine — dedicated cluster, возможно multi-region для latency.
  • Database tier — partitioning по доменам (canonical / supplier trace / booking / governance), возможно отдельные кластеры.
  • ML serving — отдельная inference infrastructure (потенциально GPU-accelerated для дорогих моделей).
  • Tenant tier isolation — premium tenants могут получать dedicated compute pool.

Обоснование: unit economics требует разной упаковки для разных профилей. ML inference на CPU-only кластере — расточительно. Dedicated tenants — конкурентное преимущество.

Триггеры выхода из фазы:

  • Регуляторные требования к data residency (GDPR + KZ + UA).
  • Multi-region expansion.
  • Premium SLO для крупных партнёров требует physical isolation.

Фаза 4 — Multi-region и dedicated infrastructure​

Цель: глобальное присутствие и enterprise-grade tenant isolation.

Упаковка:

  • Multi-region active-active для read paths (search, content, public API).
  • Multi-region active-passive для write paths (booking commit) с явной consistency model.
  • Dedicated infrastructure для enterprise tenants — отдельный cluster, отдельная database, отдельный network namespace.
  • Edge compute для high-latency regions (если CDN + edge functions релевантны для search).
  • Disaster recovery с RTO/RPO targets, geo-redundant backup.

Обоснование: enterprise-партнёры требуют SLA, которые невозможны на shared infrastructure. Регуляторы требуют data residency.

Что обязательно зафиксировано в документации сразу​

В документе Scaling and Packaging Roadmap (operations/scaling-and-packaging-roadmap.md):

  • Все 4 фазы с описанием.
  • Триггеры перехода между фазами (метрические, не временные).
  • Зависимости между фазой и доменными решениями (что должно быть готово в reference/* к каждой фазе).
  • Обоснование каждого перехода тезисами.
  • Список открытых развилок для каждой фазы.

В operations/deployment.md — текущий документ описывает execution contours; обновить ссылками на phase-specific packaging-стратегию.

В reference/implementation-technology-baseline.md — добавить раздел «Packaging strategy by phase» с явными ссылками.

Запрещённые паттерны​

  • Цементировать стратегию первой фазы как final («у нас всегда будет один Kubernetes namespace»).
  • Переходить в Фазу 3 пока не пройдены условия Фазы 2.
  • Выбирать packaging без явных триггеров (не «в Q3 2026 переедем», а «при достижении X bookings/day или Y latency p99 переедем»).

Как применять​

При написании каждого operations / deployment / infrastructure документа задаю вопросы:

  1. На какой фазе работает текущее решение?
  2. Что является триггером перехода в следующую фазу?
  3. Что должно быть готово к этому переходу в других документах?
  4. Какие тезисы обосновывают именно такую упаковку для этой фазы?

Документ инфраструктуры без указания фазы и триггеров — недостаточен.

Связанная документация​